Method and system for simultaneously supporting different block sizes on a single hard drive

ABSTRACT

A method and system where a hardware platform such as a disk drive is formatted to the largest block length it is desired to read from or write to. Using commands, data can be accessed from the drive in any block length that is equal to or less than the formatted block length.

BACKGROUND OF THE INVENTION

[0001] 1. Technical Field

[0002] The present invention relates generally to running multipleoperating systems on a single hardware platform. More particularly, thepresent invention relates to simultaneously operating multiple differentoperating systems on the same hard drive where the multiple operatingsystems support different block lengths.

[0003] 2. Description of Related Art

[0004] Computer system interfaces typically include an operating system.The operating system performs basic tasks, such as recognizing input,sending output, and keeping track of data and files.

[0005] In some computing environments, it is desirable to run more thanone operating system on a particular hardware platform simultaneously.Different operating systems may support different block lengths, or thenumber of bytes per logical block address (LBA), when accessing diskstorage. However, hardware platforms, such as hard drives, are typicallyformatted to logical block addresses of a particular size, requiring allread and write commands to or from operating systems of the hard driveto also format their commands into blocks of identical size. This meansdata can only be read or written using the block length that the drivewas initialized to when the drive was formatted.

[0006] There are currently no known methods for accessing data from ahard drive in any block size other than the formatted block size of thehard drive.

SUMMARY OF THE INVENTION

[0007] The present invention provides a system and method wherein a diskdrive is formatted to the largest block length that will be read from orwritten to it. Data is accessed from the drive in any block length equalto or less than the formatted block length, allowing multiple operatingsystems that support different block sizes to operate on the samehardware platform simultaneously.

[0008] An example implementation is described with respect to a SCSIarchitecture. However, it is noted that other hard drive interfacearchitectures such as IDE (ATA) or SATA can be modified in a similarfashion to implement the invention.

[0009] In one preferred embodiment, commands are sent to the hard drivethat initialize the logical block addresses (LBAs) to a largest blocklength that will be used in the multiple operating system platform(e.g., a single hard drive). For example, Command Descriptor Blocks(CBDs) or other equivalent entities are modified by adding, for example,two bytes to the current read and write CBDs.

[0010] Read and write operations of the formatted block length behavenormally. For an operating system that supports a smaller block length,during read, the read channel reads the entire block length. A drivecache manager strips off unrequested bytes and transfers only therequested data. During write operations for an operating system thatsupports a smaller block size, the drive writes default data to fill outextra space in the block.

[0011] Further details of this and other preferred embodiments aredescribed below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The novel features believed characteristic of the invention areset forth in the appended claims. The invention itself, however, as wellas a preferred mode of use, further objectives and advantages thereof,will best be understood by reference to the following detaileddescription of an illustrative embodiment when read in conjunction withthe accompanying drawings, wherein:

[0013]FIG. 1 shows a diagram of a computer system consistent with apreferred embodiment.

[0014]FIG. 2 shows a block diagram of a computer system consistent witha preferred embodiment.

[0015]FIG. 3A shows a standard 512 byte data block formatting.

[0016]FIG. 3B shows a standard 522 byte data block formatting.

[0017]FIG. 3C shows a modified data block according to a preferredembodiment.

[0018]FIG. 4 shows an innovative command descriptor block consistentwith a preferred embodiment.

[0019]FIG. 5 shows a process flow for implementing a preferredembodiment of the present invention.

[0020]FIG. 6 shows a process flow for implementing a preferredembodiment of the present invention.

[0021]FIG. 7 shows a process flow for implementing a preferredembodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0022] With reference now to the figures and in particular withreference to FIG. 1, a pictorial representation of a data processingsystem in which the present invention may be implemented is depicted inaccordance with a preferred embodiment of the present invention. Acomputer 100 is depicted which includes a system unit 110, a videodisplay terminal 102, a keyboard 104, storage devices 108, which mayinclude floppy drives and other types of permanent and removable storagemedia, and mouse 106. Additional input devices may be included withpersonal computer 100, such as, for example, a joystick, touchpad, touchscreen, trackball, microphone, and the like. Computer 100 can beimplemented using any suitable computer, such as an IBM RS/6000 computeror IntelliStation computer, which are products of International BusinessMachines Corporation, located in Armonk, N.Y. Although the depictedrepresentation shows a computer, other embodiments of the presentinvention may be implemented in other types of data processing systems,such as a network computer. Computer 100 also preferably includes agraphical user interface that may be implemented by means of systemssoftware residing in computer readable media in operation withincomputer 100.

[0023] With reference now to FIG. 2, a block diagram of a dataprocessing system is shown in which the present invention may beimplemented. Data processing system 200 is an example of a computer,such as computer 100 in FIG. 1, in which code or instructionsimplementing the processes of the present invention may be located. Dataprocessing system 200 employs a peripheral component interconnect (PCI)local bus architecture. Although the depicted example employs a PCI bus,other bus architectures such as Accelerated Graphics Port (AGP) andIndustry Standard Architecture (ISA) may be used. Processor 202 and mainmemory 204 are connected to PCI local bus 206 through PCI bridge 208.PCI bridge 208 also may include an integrated memory controller andcache memory for processor 202. Additional connections to PCI local bus206 may be made through direct component interconnection or throughadd-in boards. In the depicted example, local area network (LAN) adapter210, small computer system interface SCSI host bus adapter 212, andexpansion bus interface 214 are connected to PCI local bus 206 by directcomponent connection. In contrast, audio adapter 216, graphics adapter218, and audio/video adapter 219 are connected to PCI local bus 206 byadd-in boards inserted into expansion slots. Expansion bus interface 214provides a connection for a keyboard and mouse adapter 220, modem 222,and additional memory 224. SCSI host bus adapter 212 provides aconnection for hard disk drive 226, tape drive 228, and CD-ROM drive230. Typical PCI local bus implementations will support three or fourPCI expansion slots or add-in connectors.

[0024] An operating system runs on processor 202 and is used tocoordinate and provide control of various components within dataprocessing system 200 in FIG. 2. The operating system may be acommercially available operating system such as Windows 2000, which isavailable from Microsoft Corporation. An object oriented programmingsystem such as Java may run in conjunction with the operating system andprovides calls to the operating system from Java programs orapplications executing on data processing system 200. “Java” is atrademark of Sun Microsystems, Inc. Instructions for the operatingsystem, the object-oriented programming system, and applications orprograms are located on storage devices, such as hard disk drive 226,and may be loaded into main memory 204 for execution by processor 202.

[0025] Those of ordinary skill in the art will appreciate that thehardware in FIG. 2 may vary depending on the implementation. Otherinternal hardware or peripheral devices, such as flash ROM (orequivalent nonvolatile memory) or optical disk drives and the like, maybe used in addition to or in place of the hardware depicted in FIG. 2.Also, the processes of the present invention may be applied to amultiprocessor data processing system.

[0026] For example, data processing system 200, if optionally configuredas a network computer, may not include SCSI host bus adapter 212, harddisk drive 226, tape drive 228, and CD-ROM 230, as noted by dotted line232 in FIG. 2 denoting optional inclusion. In that case, the computer,to be properly called a client computer, must include some type ofnetwork communication interface, such as LAN adapter 210, modem 222, orthe like. As another example, data processing system 200 may be astand-alone system configured to be bootable without relying on sometype of network communication interface, whether or not data processingsystem 200 comprises some type of network communication interface. As afurther example, data processing system 200 may be a personal digitalassistant (PDA), which is configured with ROM and/or flash ROM toprovide non-volatile memory for storing operating system files and/oruser-generated data.

[0027] The depicted example in FIG. 2 and above-described examples arenot meant to imply architectural limitations. For example, dataprocessing system 200 also may be a notebook computer or hand heldcomputer in addition to taking the form of a PDA. Data processing system200 also may be a kiosk or a Web appliance.

[0028] The processes of the present invention are performed by processor202 using computer implemented instructions, which may be located in amemory such as, for example, main memory 204, memory 224, or in one ormore peripheral devices 226-230.

[0029] In the present invention is preferably implemented in a SCSIarchitecture, though other comparable interfaces are also within thescope of the present invention.

[0030] In a SCSI architecture, hard drive block size is defined byperforming a Mode Select Command with the block size specified in theBlock Descriptor Block Length Field. The Mode Select Command is sent tothe hard drive, then the Format Unit Command is sent to the hard drive.This initializes all of the logical block addresses (LBAs) to thespecified block length. Read and Write commands transfer data inincrements of bytes defined by the block length.

[0031] The present invention provides a system and method for formattinga hardware platform (such as a hard drive) to use logical blockaddresses of the maximum size to be used by any of a plurality ofoperating systems present on the platform. For example two differentOS's may support different LBAs. Then, data is sent to and from the harddrive, and if the data is formatted into blocks of less than the maximumformatted size, extraneous bits are either added to fill in the datablock, or extraneous bits are stripped from the data block, as requiredin the individual case. This allows a hardware platform formatted to oneblock length to simultaneously support operating systems that usedifferent block lengths. Example implementations are described below.

[0032]FIG. 3A shows a standard 512 byte data block formatting. In thisexample data block, data 302 occupies 512 bytes of the block while errorcontrol coding (ECC) or cyclic redundancy check (CRC) bytes 304 areappended to the block. FIG. 3B shows standard formatting for a 522 bytedata block. 522 bytes of data 306 occupy the block along with ECC bytes308.

[0033]FIG. 3C shows a data block consistent with a preferred embodimentof the present invention. In this example, the data block is for a harddrive formatted for 522 byte LBAs. However, only 512 bytes are occupiedby data 302, because this example LBA is intended to communicate with anoperating system that supports 512 byte LBAs. The remaining bytes areoccupied by pad 310 sand ECC 308.

[0034] Such a block as depicted in FIG. 3C is consistent with a harddrive formatted for 522 byte LBAs, but also allows reads and writes byoperating systems that support 512 byte LBAs. For example, inimplementations where there are two OSs on the hardware platform, afirst OS may support 522 byte addressing while a second OS may supportonly 512 byte addressing. When the first OS communicates with the harddrive, it sends and receives data in both the data section 302 of theblock and in the pad section 310, allowing the full 522 bytes to becommunicated.

[0035] When the second OS communicates with the hard drive, it sends andreceives data in only the data section 302, and filler data fills padsection 310. During read, the read channel reads the entire data lengthdefined by the block length and puts the data into cache. The drivecache manager strips off any unrequested bytes (i.e., the pad section310) and transfers the requested data across the SCSI to the SCSIinitiator, appending the correct ECC bytes to the data of each block.During write, the SCSI data phase transfers the full block of data. Ifthe number of bytes to be written are less than the block size to whichthe hardware is formatted, the drive writes the default pad data patternto fill out the block. In preferred embodiments, the default pad data isa predetermined bit, such as all zeros.

[0036] In a first embodiment, implementation of the above describedprocedures requires a change to the various operating systems to remapthe currently used Read and Write CDBs. For example, Read 12 and Write12 CDBs are remapped to Read 14 and Write 14 commands, as describedbelow. No other changes are required to accommodate the different blocksizes and the current SCSI protocol.

[0037] In a first preferred embodiment of the present invention, theCommand Descriptor Block (CDB) is altered by adding two bytes to thecurrent Read 12 and Write 12 CDBs, making them Read14 and Write 14 CDBs.The new lines are shown in FIG. 4, which depicts the altered CDB of thisexample implementation. The drive returns only the length of dataspecified in the bytes transferred field of the new Read 14 and Write 14CDBs.

[0038] In FIG. 4, the CDB shows the several bytes of the CDB. In thisexample, lines 11 (‘Bytes Transferred (MSB)’)and 12 (‘Bytes Transferred(LSB)’) show the newly added lines. These indicate to the hard drive thesize of data blocks to be transferred in read and write operations. Theplacement of the added bytes in the CDB is preferably done to minimizethe effect on the CDB structure for the CDBs affected. In this manner,there is minimal effect on the device driver CDB parsing routine.

[0039]FIG. 5 shows a process flow for implementing a preferredembodiment of the present invention. It is described in a contextwherein the hardware platform (e.g., hard drive) is formatted to thelargest block size that will be requested from the drive. The CDB ismodified by adding two “Bytes Transferred” fields, which indicate theamount of data to be transferred

[0040] When a read is desired, a Read 14 CDB is generated with the bytesof data indicated in the Bytes Transferred fields of the CDB (step 502).When Read 14 CDB is sent to the drive, the drive servo seeks to the LBAand the read channel reads the entire data length defined by the blocklength and puts the data into cache (step 504). The drive cache manageruses the bytes transferred field of the CDB to determine if the amountof data transferred equals the amount of data received (step 506). Thedrive cache manager strips off any unrequested bytes (i.e., bytes beyondthose indicated in the Bytes Transferred field of the CDB) (step 508).The cache manager transfers the requested data across the interface(e.g., SCSI) to the SCSI initiator, appending the correct CRC bytes tothe data of each block (step 510).

[0041] Write operations for this example preferred embodiment areperformed in the same contest of a modified CDB, as described above.FIG. 6 shows an example flowchart. When the modified write 14 CDB issent to the drive, the subsequent SCSI data phase transfers the numberof bytes specified in the bytes transferred field of the CDB to the harddrive, followed by the CRC bytes for each block (step 602). The drivethen seeks to the LBA and writes the data sent by the initiator (step604). If the number of bytes to be written are less than the block sizeof the drive, the drive writes a default pad data pattern to fill outthe block (step 606).

[0042] Note that if the system chooses to send Read 12 or Write 12 CDBsthen the number of bytes of data transferred is set by the block sizethe drive was formatted to initially. That is, the drive still supportsall CDBs defined in the ANSI Standards in the manner required by thesestandards.

[0043] In another example implementation, the CDB is not altered butinstead, a new SCSI command is defined. Note that though this example isdescribed with respect to SCSI architecture, the invention is notlimited to this architecture as described above. The following exampleis described in the context of a newly defined SCSI command that definesthe block size, and hence the number of bytes transferred to and fromthe host when the SCSI Read/Write commands are used. For example, the“Change Definition” command can be modified to add a transfer lengthfield which indicates to the hardware platform the block size.

[0044] The process, shown in FIG. 7, begins when the operating system isstarted(step 702). The operating system SCSI device driver sends theChange Definition command to a hard drive, before sending any mediaaccess commands (step 704). Note that a field is added to the ChangeDefinition command that defined the block size that will be used for allmedia access commands received by the drive. This block size remains inplace until after another Change Def command is sent to the drivechanging the value again (e.g., back to the originally formatted value)(step 706). The SCSI command preferably sets the transfer size on a perSCSI initiator basis. For a system containing multiple logicalpartitions, each partition must send the command to the drive beforeaccessing the media to assure the transfer size is correct.

[0045] The present invention allows concurrent operation of multipleoperating systems (e.g., AIX, OS/400) that support different sizelogical block addresses on a single hardware platform. Using the methodsdescribed herein, the disk drive remains in full compliance with theANSI SCSI Block Commands Specification. The present invention, thoughdescribed with reference to SCSI architecture, can be implemented withother architectures such as IDE (ATA) or SATA, for example.

[0046] The description of the present invention has been presented forpurposes of illustration and description, and is not intended to beexhaustive or limited to the invention in the form disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art. The embodiment was chosen and described in order to bestexplain the principles of the invention, the practical application, andto enable others of ordinary skill in the art to understand theinvention for various embodiments with various modifications as aresuited to the particular use contemplated.

What is claimed is:
 1. A computer system, comprising: a hard driveformatted to support logical block addresses of a first size; a cachemanager that determines if a read command includes a logical blockaddress of the first size; wherein if the logical block address is notof the first size, the cache manager changes the logical block addressto the first size.
 2. The system of claim 1, wherein the first size is522 bytes.
 3. The system of claim 1, wherein the cache manager changesthe logical block address to the first size by adding filler data to thelogical block address.
 4. The system of claim 1, wherein the hard driveincludes SCSI architecture.
 5. The system of claim 1, wherein thecommand is a read command.
 6. The system of claim 1, wherein the cachemanager is a cache manager for the hard drive.
 7. A method of accessinga hard drive, comprising the steps of: sending a read command to thehard drive to read a first logical block address; reading the data ofthe first logical block address; storing the data of the first logicalblock address in a cache; comparing the data of the first logical blockaddress with an indication of the bytes to be transferred; and strippingoff unrequested bytes from the data of the first logical block address.8. The system of claim 7, wherein the indication of the bytes to betransferred is a Bytes Transferred field of a read command descriptorblock (CDB).
 9. The system of claim 7, wherein the step of sending aread command includes sending a read command descriptor block (CDB) thatindicates the number of bytes transferred.
 10. The system of claim 7,wherein steps of comparing and stripping are performed by a drive cachemanager.
 11. A method of accessing a hard drive, comprising the stepsof: sending a write command to the hard drive to write first data to alogical block address of a first size; writing the first data to thelogical block address of the first size; if first data is fewer bytesthan the first size of the logical block address, writing second data tofill out the logical block address.
 12. The system of claim 11, whereinthe second data is a default pad data pattern.
 13. A method of accessinga computer system having a hard drive formatted to support a logicalblock address of a first size, comprising the steps of: sending a firstcommand to the hard drive to define a number of bytes transferred to orfrom the hard drive, the number of bytes transferred being consistentwith a logical block address of a second size; sending a read/writecommand to the hard drive, wherein the read/write command is for data ofa logical block address of the second size; sending a second command tothe hard drive to reset the logical block addresses of the hard drive tothe first size.
 14. The system of claim 13, wherein the second size issmaller than the first size.
 15. The system of claim 13, wherein thefirst and second commands are sent to the hard drive by a SCSI devicedriver.
 16. The method of claim 13, further comprising the steps of:adding a field to the command descriptor block to indicate the number ofbytes transferred in a command; comparing the number of bytestransferred in the command to the number of bytes in a logical blockaddress of a hard drive.
 17. A system for accessing a hard drive,comprising: means for sending a read command to the hard drive to read afirst logical block address; means for reading the data of the firstlogical block address; means for storing the data of the first logicalblock address in a cache; means for comparing the data of the firstlogical block address with an indication of the bytes to be transferred;and means for stripping off unrequested bytes from the data of the firstlogical block address.
 18. The system of claim 17, wherein theindication of the bytes to be transferred is a Bytes Transferred fieldof a read command descriptor block (CDB).
 19. The system of claim 17,wherein the means for sending a read command send a read commanddescriptor block (CDB) that indicates the number of bytes transferred.20. The system of claim 17, wherein the means for comparing and meansfor stripping comprise a drive cache manager.
 21. A system for accessinga hard drive, comprising: means for sending a write command to the harddrive to write first data to a logical block address of a first size;means for writing the first data to the logical block address of thefirst size; means for, if first data is fewer bytes than the first sizeof the logical block address, writing second data to fill out thelogical block address.
 22. The system of claim 21, wherein the seconddata is a default pad data pattern.
 23. A computer program product foraccessing a computer system having a hard drive formatted to support alogical block address of a first size, comprising the computerimplemented steps of: sending a first command to the hard drive todefine a number of bytes transferred to or from the hard drive, thenumber of bytes transferred being consistent with a logical blockaddress of a second size; sending a read/write command to the harddrive, wherein the read/write command is for data of a logical blockaddress of the second size; sending a second command to the hard driveto reset the logical block addresses of the hard drive to the firstsize.
 24. The system of claim 23, wherein the second size is smallerthan the first size.
 25. The system of claim 23, wherein the first andsecond commands are sent to the hard drive by a SCSI device driver. 26.A computer system, comprising: a hard drive formatted to logical blockaddresses of a first size; first and second operating systems runningsimultaneously on the computer system, the first operating system usinga logical block address of a second size, the second operating systemusing a logical block address of a third size; wherein the firstoperating system sends read and write commands to the hard drive fordata in blocks of the second size, and wherein the second operatingsystem sends read and write commands to the hard drive for data inblocks of the third size.
 27. The system of claim 26, wherein the firstsize is larger than the second size.
 28. The system of claim 26, whereinthe first size is 522 bytes, and wherein the second size is 522 bytes,and wherein the third size is 512 bytes.